Extension and node URNs now share one canonical 4-segment shape
`urn:<namespace>:<kind>:<id>` (e.g., `urn:microsoft:extension:azure_identity_auth`),
mirroring the receiver/processor/exporter convention. Short forms
`<kind>:<id>` work for both, expanding to `urn:otel:<kind>:<id>`.

The previous 3-segment extension form (`urn:<ns>:<id>`) is no longer
accepted. Misplacement errors include actionable hints, e.g.
'(declare under `extensions:` instead of `nodes:`)'.

- New private `crates/config/src/urn.rs` factors out the shared
  parser core (`parse_kinded_urn`, `build_canonical_urn`, segment
  validators, misplacement-hint formatter).
- `node_urn.rs` and `extension_urn.rs` now delegate to it; their
  accepted-kind sets are disjoint, so `NodeUrn` can never parse an
  extension URN and vice versa.
- Removed `NodeKind::Extension` from the node enum and all defensive
  match arms in `pipeline.rs`, `controller/lib.rs`,
  `controller/startup.rs`, `engine/lib.rs`.
- Removed `Error::ExtensionInNodesSection` (became unreachable —
  type-rejected at parse).
- Updated YAML fixtures, bundled `configs/fake-with-extension.yaml`,
  and all `extension_e2e.rs` test URN constants to the 4-segment form.
- Added regression tests for misplacement-hint error messages.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…em-p1-pr4

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…em-p1-pr4

… validation

The file contains Jinja placeholders ({{core_start}}, {{core_end}}) but
was missing the .j2 suffix, so the validate-configs CI script picked it
up as a real config and failed YAML parsing. Sibling otlp-otlp.yaml.j2
and otlphttp-otlphttp.yaml.j2 already use the .j2 convention; align
otap-otap with them and update the three suite references.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Address review feedback on PR open-telemetry#2860: the requirements doc described
`shared` as "one runtime instance shared across cores", which conflicts
with the architecture doc's correct statement that pipeline-scoped
shared extensions are still instantiated per pipeline instance (per
core). Reconcile both docs around the same model:

- Execution model (`local` / `shared`) defines the *type constraints*
- Sharing boundary is determined by the *scope* at which the extension
  is declared. In Phase 1 the only scope is pipeline, so `shared`
  extensions are per-pipeline-instance (per core), with the `Send +
  Clone` bounds enabling true cross-core sharing later when group /
  engine scopes land.

Changes:

- extension-requirements.md: rewrite the execution-model table to
  surface type constraints and Phase 1 sharing boundary explicitly,
  add a Phase 1 callout for `shared`, and reframe the surrounding
  prose so it no longer reads as "shared = cross-core in Phase 1".
- extension-system-architecture.md: append a forward pointer in the
  thread-per-core requirement row so a table-only reader sees the
  per-core caveat already documented further down.

Refs: open-telemetry#2860 (comment)

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

The config referenced `urn:otap:extension:sample_shared_key_value_store`,
which has no registered ExtensionFactory anywhere in the binary. Until
this PR's earlier validation tightening (f9a67ea) the validate-configs
CI job missed it because extension URNs weren't walked. With the fix in
place, this YAML now fails validate-configs.

It also has no test/script/doc consumers — only the validate-configs
sweep was loading it. The schema is still demonstrated by the
`test_extension_with_config_and_capabilities` unit test in
crates/config/src/pipeline.rs, so deleting the orphan loses no
documentation value. A runnable demo extension can land in a follow-up
alongside a real factory.

Refs: open-telemetry#2860 (comment)

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Add a "Runtime cost" sub-paragraph under the existing "Extensions
start first, shut down last" key design decision in
extension-system-architecture.md. Spells out that start() (and any
capability method dispatched on that runtime) shares the per-core
async runtime with the data path, so blocking I/O or CPU-heavy work
in those bodies starves the pipeline on that core. Recommends
spawn_blocking, a worker thread, or Rayon for off-runtime work. Same
guidance applies to background extensions.

Refs: open-telemetry#2860 (comment)

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>